Network PC

home *** CD-ROM | disk | FTP | other *** search

/ Network PC / Network PC.iso / amiga utilities / communication / internet / amitcp3.0b / doc / devtools.doc < prev next >

Wrap

Text File | 1997-11-21 | 20.9 KB | 513 lines

TABLE OF CONTENTS devtools.doc/cpp devtools.doc/rpcgen utilities/rcsrev devtools.doc/cpp devtools.doc/cpp NAME cpp - C Pre-Processor SYNOPSIS cpp [-options] [infile [outfile]] DESCRIPTION CPP reads a C source file, expands macros and include files, and writes an input file for the C compiler. If no file arguments are given, CPP reads from stdin and writes to stdout. If one file argument is given, it will define the input file, while two file arguments define both input and output files. The file name "-" is a synonym for stdin or stdout as appropriate. The following options are supported. Options may be given in either case. -C If set, source-file comments are written to the output file. This allows the output of CPP to be used as the input to a program, such as lint, that expects commands embedded in specially-formatted comments. -Dname=value Define the name as if the programmer wrote #define name value at the start of the first file. If "=value" is not given, a value of "1" will be used. On non-unix systems, all alphabetic text will be forced to upper-case. -E Always return "success" to the operating system, even if errors were detected. Note that some fatal errors, such as a missing #include file, will terminate CPP, returning "failure" even if the -E option is given. -Idirectory Add this directory to the list of directories searched for #include "..." and #include <...> commands. Note that there is no space between the "-I" and the directory string. More than one -I command is permitted. On non-Unix systems "directory" is forced to upper-case. -N CPP normally predefines some symbols defining the target computer and operating system. If -N is specified, no symbols will be predefined. If -N -N is specified, the "always present" symbols, __LINE__, __FILE__, and __DATE__ are not defined. -P Do not output #line directives. -Stext CPP normally assumes that the size of the target computer's basic variable types is the same as the size of these types of the host computer. (This can be overridden when CPP is compiled, however.) The -S option allows dynamic respecification of these values. "text" is a string of numbers, separated by commas, that specifies correct sizes. The sizes must be specified in the exact order: char short int long float double If you specify the option as "-S*text", pointers to these types will be specified. -S* takes one additional argument for pointer to function (e.g. int (*)()) For example, to specify sizes appropriate for a PDP-11, you would write: c s i l f d func -S1,2,2,2,4,8, -S*2,2,2,2,2,2,2 Note that all values must be specified. -Uname Undefine the name as if #undef name were given. On non-Unix systems, "name" will be forced to upper-case. -Xnumber Enable debugging code. If no value is given, a value of 1 will be used. (For maintenence of CPP only.) PRE-DEFINED VARIABLES When CPP begins processing, the following variables will have been defined (unless the -N option is specified): Target computer (as appropriate): pdp11, vax, M68000 m68000 m68k Target operating system (as appropriate): rsx, rt11, vms, unix Target compiler (as appropriate): decus, vax11c The implementor may add definitions to this list. The default definitions match the definition of the host computer, operating system, and C compiler. The following are always available unless undefined (or -N was specified twice): __FILE__ The input (or #include) file being compiled (as a quoted string). __LINE__ The line number being compiled. __DATE__ The date and time of compilation as a Unix ctime quoted string (the trailing newline is removed). Thus, printf("Bug at line %s,", __LINE__); printf(" source file %s", __FILE__); printf(" compiled on %s", __DATE__); DRAFT PROPOSED ANSI STANDARD CONSIDERATIONS The current version of the Draft Proposed Standard explicitly states that "readers are requested not to specify or claim conformance to this draft." Readers and users of Decus CPP should not assume that Decus CPP conforms to the standard, or that it will conform to the actual C Language Standard. When CPP is itself compiled, many features of the Draft Proposed Standard that are incompatible with existing preprocessors may be disabled. See the comments in CPP's source for details. The latest version of the Draft Proposed Standard (as reflected in Decus CPP) is dated November 12, 1984. Comments are removed from the input text. The comment is replaced by a single space character. The -C option preserves comments, writing them to the output file. The '$' character is considered to be a letter. This is a permitted extension. The following new features of C are processed by CPP: #elif expression (#else #if) '\xNNN' (Hexadecimal constant) '\a' (Ascii BELL) '\v' (Ascii Vertical Tab) #if defined NAME 1 if defined, 0 if not #if defined (NAME) 1 if defined, 0 if not #if sizeof (basic type) unary + 123U, 123LU Unsigned ints and longs. 12.3L Long double numbers token#token Token concatenation #include token Expands to filename The Draft Proposed Standard has extended C, adding a constant string concatenation operator, where "foo" "bar" is regarded as the single string "foobar". (This does not affect CPP's processing but does permit a limited form of macro argument substitution into strings as will be discussed.) The Standard Committee plans to add token concatenation to #define command lines. One suggested implementation is as follows: the sequence "Token1#Token2" is treated as if the programmer wrote "Token1Token2". This could be used as follows: #line 123 #define ATLINE foo#__LINE__ ATLINE would be defined as foo123. Note that "Token2" must either have the format of an identifier or be a string of digits. Thus, the string #define ATLINE foo#1x3 generates two tokens: "foo1" and "x3". If the tokens T1 and T2 are concatenated into T3, this implementation operates as follows: 1. Expand T1 if it is a macro. 2. Expand T2 if it is a macro. 3. Join the tokens, forming T3. 4. Expand T3 if it is a macro. A macro formal parameter will be substituted into a string or character constant if it is the only component of that constant: #define VECSIZE 123 #define vprint(name, size) \ printf("name" "[" "size" "] = {\n") ... vprint(vector, VECSIZE); expands (effectively) to vprint("vector[123] = {\n"); Note that this will be useful if your C compiler supports the new string concatenation operation noted above. As implemented here, if you write #define string(arg) "arg" ... string("foo") ... This implementation generates "foo", rather than the strictly correct ""foo"" (which will probably generate an error message). This is, strictly speaking, an error in CPP and may be removed from future releases. ERROR MESSAGES Many. CPP prints warning or error messages if you try to use multiple-byte character constants (non-transportable) if you #undef a symbol that was not defined, or if your program has potentially nested comments. AUTHOR Martin Minow BUGS The #if expression processor uses signed integers only. I.e, #if 0xFFFFu < 0 may be TRUE. devtools.doc/rpcgen devtools.doc/rpcgen NAME rpcgen - an RPC protocol compiler SYNOPSIS rpcgen infile rpcgen [-Dname[=value]] [-T] [-K secs] infile rpcgen -c|-h|-l|-m|-t [-o outfile ] infile rpcgen [-I] -s nettype [-o outfile] infile rpcgen -n netid [-o outfile] infile DESCRIPTION rpcgen is a tool that generates C code to implement an RPC protocol. The input to rpcgen is a language similar to C known as RPC Language (Remote Procedure Call Language). rpcgen is normally used as in the first synopsis where it takes an input file and generates up to four output files. If the infile is named proto.x, then rpcgen will generate a header file in proto.h, XDR routines in proto_xdr.c, server-side stubs in proto_svc.c, and client-side stubs in proto_clnt.c. With the -T option, it will also generate the RPC dispatch table in proto_tbl.i. With the -Sc option, it will also generate sample code which would illustrate how to use the remote procedures on the client side. This code would be created in proto_client.c. With the -Ss option, it will also generate a sample server code which would illustrate how to write the remote procedures. This code would be created in proto_server.c. The server created can be started both by the port monitors (for example, inetd or listen) or by itself. When it is started by a port monitor, it creates servers only for the transport for which the file descriptor 0 was passed. The name of the transport must be specified by setting up the environmental variable PM_TRANSPORT. When the server generated by rpcgen is executed, it creates server handles for all the transports specified in NETPATH environment variable, or if it is unset, it creates server handles for all the visible transports from /etc/netconfig file. Note: the transports are chosen at run time and not at compile time. When the server is self-started, it backgrounds itself by default. A special define symbol RPC_SVC_FG can be used to run the server process in foreground. The second synopsis provides special features which allow for the creation of more sophisticated RPC servers. These features include support for user provided #defines and RPC dispatch tables. The entries in the RPC dispatch table contain: + pointers to the service routine corresponding to that procedure, + a pointer to the input and output arguments + the size of these routines A server can use the dispatch table to check authorization and then to execute the service routine; a client library may use it to deal with the details of storage management and XDR data conversion. The other three synopses shown above are used when one does not want to generate all the output files, but only a particular one. Some examples of their usage is described in the EXAMPLE section below. When rpcgen is executed with the -s option, it creates servers for that particular class of transports. When executed with the -n option, it creates a server for the transport specified by netid. If infile is not specified, rpcgen accepts the standard input. The C preprocessor, ccp, is run on the input file before it is actually interpreted by rpcgen. For each type of output file, rpcgen defines a special preprocessor symbol for use by the rpcgen programmer: RPC_HDR defined when compiling into header files RPC_XDR defined when compiling into XDR routines RPC_SVC defined when compiling into server-side stubs RPC_CLNT defined when compiling into client-side stubs RPC_TBL defined when compiling into RPC dispatch tables Any line beginning with `%' is passed directly into the output file, uninterpreted by rpcgen. For every data type referred to in infile, rpcgen assumes that there exists a routine with the string xdr_ prepended to the name of the data type. If this routine does not exist in the RPC/XDR library, it must be provided. Providing an undefined data type allows customization of XDR routines. The following options are available: -a Generate all the files including sample code for client and server side. -b This generates code for the SunOS4.1 style of rpc. It is for backward compatibilty. This is the default. -5 This generates code for the SysVr4 style of rpc. It is used by the Transport Independent RPC that is in Svr4 systems. By default rpcgen generates code for SunOS4.1 stype of rpc. -c Compile into XDR routines. -C Generate code in ANSI C. This option also generates code that could be compiled with the C++ compiler. This is the default. -k Generate code in K&R C. The default is ANSI C. -Dname[=value] Define a symbol name. Equivalent to the #define directive in the source. If no value is given, value is defined as 1. This option may be specified more than once. -h Compile into C data-definitions (a header file). -T option can be used in conjunction to produce a header file which supports RPC dispatch tables. -I Generate a service that can be started from inetd. The default is to generate a static service that handles transports selected with -s. Using -I allows starting a service by either method. -K secs By default, services created using rpcgen wait 120 seconds after servicing a request before exiting. That interval can be changed using the -K flag. To create a server that exits immediately upon servicing a request, -K 0 can be used. To create a server that never exits, the appropriate argument is -K -1. When monitoring for a server, some portmonitors, like listen(1M), always spawn a new process in response to a service request. If it is known that a server will be used with such a monitor, the server should exit immediately on completion. For such servers, rpcgen should be used with -K -1. -l Compile into client-side stubs. -m Compile into server-side stubs, but do not generate a main routine. This option is useful for doing callback-routines and for users who need to write their own main routine to do initialization. -n netid Compile into server-side stubs for the transport specified by netid. There should be an entry for netid in the netconfig database. This option may be specified more than once, so as to compile a server that serves multiple transports. -N Use the newstyle of rpcgen. This allows procedures to have multiple arguments. It also uses the style of parameter passing that closely resembles C. So, when passing an argument to a remote procedure you do not have to pass a pointer to the argument but the argument itself. This behaviour is different from the oldstyle of rpcgen generated code. The newstyle is not the default case because of backward compatibility. -o outfile Specify the name of the output file. If none is specified, standard output is used (-c, -h, -l, -m, -n, -s, -sSc, -sSs and -t modes only). -s nettype Compile into server-side stubs for all the transports belonging to the class nettype. The supported classes are netpath, visible, circuit_n, circuit_v, datagram_n, datagram_v, tcp, and udp [see rpc(3N) for the meanings associated with these classes]. This option may be specified more than once. Note: the transports are chosen at run time and not at compile time. -Sc Generate sample code to show the use of remote procedure and how to bind to the server before calling the client side stubs generated by rpcgen. -Ss Generate skeleton code for the remote procedures on the server side. You would need to fill in the actual code for the remote procedures. -t Compile into RPC dispatch table. -T Generate the code to support RPC dispatch tables. The options -c, -h, -l, -m, -s and -t are used exclusively to generate a particular type of file, while the options -D and -T are global and can be used with the other options. NOTES The RPC Language does not support nesting of structures. As a work- around, structures can be declared at the top-level, and their name used inside other structures in order to achieve the same effect. Name clashes can occur when using program definitions, since the apparent scoping does not really apply. Most of these can be avoided by giving unique names for programs, versions, procedures and types. The server code generated with -n option refers to the transport indicated by netid and hence is very site specific. EXAMPLE The following example: $ rpcgen -T prot.x generates the five files: prot.h, prot_clnt.c, prot_svc.c, prot_xdr.c and prot_tbl.i. The following example sends the C data-definitions (header file) to the standard output. $ rpcgen -h prot.x To send the test version of the -DTEST, server side stubs for all the transport belonging to the class datagram_n to standard output, use: $ rpcgen -s datagram_n -DTEST prot.x To create the server side stubs for the transport indicated by netid tcp, use: $ rpcgen -n tcp -o prot_svc.c prot.x SEE ALSO devtools.doc/cpp utilities/rcsrev utilities/rcsrev NAME RCSRev - Convert a RCS ID into #?_rev.? Files VERSION $Id: rcsrev.c,v 2.3 1994/03/08 00:36:12 ppessi Exp $ TEMPLATE RCSREV NAME/A SOURCE/A POSTFIX ASM=ASMINCLUDE/S DATE/K FUNCTION RCSRev is intended to generate a BumbRev-compatible revision include files from RCS ID. The arguments are used as follows: NAME/A - name for program (generate file NAME_rev.h). SOURCE/A - source file name PREFIX/K - optional prefix to program name (eg. AmiTCP/IP_) POSTFIX/K - optional string postfixed to revision string ASMINCLUDE/S - create also an assembler include file (generate file NAME_rev.i). DATE/K - specify the date format used. The date formats available are as follows: CURRENT - use current date (default) RCS - use date from RCS ID SASC - use preprocessor macro __AMIGADATE__ DICE - use preprocessor macro __COMMODORE_DATE__ NOTES The macro DATE is not defined in the revision file with SASC or COMMODORE date formats. The macro VSTRING is not defined in revision file with the SASC format. (See sources and macro FIXED_AMIGADATE). The SASC or DICE formats can not be used with the ASMINCLUDE option. BUGS RCSRev doesn't recognize other RCS ident string except Id. Maximum allowed line length is fixed. AUTHOR ppessi <Pekka.Pessi@hut.fi> COPYRIGHT Copyright © 1993 AmiTCP/IP Group, <AmiTCP-group@hut.fi>, Helsinki University of Technology, Finland.